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Abstract 

The  Submarine  Message  Buffer  (SMB)  is  a  real  time 
embedded  message  processing  system  developed  at  the 
Naval  Command,  Control  and  Ocean  Surveillance  Center, 
Research,  Development,  Test  and  Evaluation  Division 
(NRaD).  The  SMB  is  sponsored  by  the  Space  and  Naval 
Warfare  Systems  Command  (SPAWAR)  to  support 
modernization  of  SSN  (Los  Ange's  and  Seawolf  class 
submarines)  radio  rooms.  The  development  strategy 
adopted  for  the  SMB  concentrated  on  the  reuse  of  Ada 
software.  This  paper  will  focus  on  the  design,  processes 
and  methodologies,  which  were  used  in  the  development  of 
this  system.  Metrics  will  also  be  provided  showing  why 
this  system  has  been  identified  as  an  Ada  success  story  by 
the  Ada  Joint  Program  Office  among  others  [12]. 

Introduction 

Figure  1  is  a  block  diagram  of  the  SMB.  The  SMB 
is  a  real  time  message  processor  that  can  receive  and 
transmit  messages  from  various  RF  modems  on  the  SSN 
via  four  AN/UGC- 1 36C(X)  Teletypes  while  simultaneously 
performing  other  standard  message  processing  functions. 
These  functions  include  identifying  the  message  type, 
parsing  out  key  message  elements  and  inputting  the 
messages  into  a  database.  The  SMB  also  enables  an 
operator  to  perform  standard  message  management  activities 
according  to  standard  Naval  procedures.  These  activities 
include  maintenance  of  message  audit  trails,  providing  an 
automated  radio  log,  word  processing  and  message  template 
forms  for  message  composition  (ACP-126,  ACP-127, 
JANAP-128,  JINTACCS).  The  SMB  can  also  get 
messages  through  the  operator  interface  or  floppy  disk. 

The  SMB  is  targeted  for  an  80386  Personal 
Computer  with  I/O  boards  which  reside  on  the  ISA  bus. 
These  I/O  boards  are  single  board  computers  based  on  Intel 


Naval  Warfare  Systems 
271  Catalma  Blvd 
San  Diego  Ca  92 152-6550 


80186  processors  which  provide  four  full  duplex  channels 
per  board.  They  are  programmable  and  allow  for  the  use  of 
various  communication  interfaces  and  protocols. 

Microsoft's  MS-DOS^ M  was  chosen  as  the 
operating  system  to  maximize  the  use  of  commercial-off 
the -shelf  software  and  reuse  of  government  owned  software. 


computer  patch  teletype 

panel 


Figure  1.  SMB  Block  Diagram 

Many  of  the  functions  required  of  the  SMB  arc 
similar  to  other  military  message  processing  systems 
already  developed  and  fielded.  Further,  one  of  the  mission 
focus  areas  for  the  NRaD  Operational  Systems  Branch  is 
the  development  and  maintenance  of  message  processing 
systems.  For  these  reasons  a  search  to  identify  a  library  of 
reusable  message  processing  software  was  initiated. 

The  initial  search  identified  a  number  of  candidates 
whose  specifications  were  put  into  the  library.  These 
candidates  were  evaluated  by  a  preset  strategy  (3).  This 
evaluation  resulted  in  identifying  two  candidate  Ada 
programs,  the  JINTACCS  Automated  Message  Editing 
System  (JAMES)  and  the  NATO  Interoperable  Submarine 
Broadcast  System  (NISBS)  that  were  to  be  reused  for  the 


SMB.  Together,  these  two  programs  provider)  XlVv  of  lire 
desired  functionality  of  die  SMB. 

Design 

The  SMB  is  composed  of  (he  following  ihrcc 
subsystems:  User  Interface.  Message  Processing,  and 
Input/Output  Subsystems.  JAMES  was  the  source  of  the 
User  Interface  and  Message  Processing  Subsystems 
software.  The  Input/Output  Subsystem  software,  called 
lOJTOOLS,  was  obtained  from  NISBS.  JAMES  is  similar 
to  character  based  commercial  word  processing  programs 
for  MS-DOS.  It  provides  the  capability  to  edit,  retrieve, 
create,  print  and  save  messages  in  files.  Also,  like 
commercial  word  processors  for  MS-DOS,  it  has  no  real 
time,  multiprocessing  capabilities.  The  lOJTOOLS 
provide  the  real  time  capability  and  are  the  key  to  the  reuse 
success  on  this  project. 

The  IO_TOOLS  were  developed  for  the  NISBS 
program  under  an  Ada  Technology  Insertion  Program 
(ATEP)  grant  from  the  Ada  Joint  Program  Office  (AJPO). 
These  tools  were  designed  for  maximum  reusability  and 
leverage  PC  technology  to  provide  an  inexpensive  yet  very 
powerful  real  time  multichannel  system.  The  overall 
design  of  the  IO_TOOLS  was  based  on  a  layered  approach 
to  system  composition  as  shown  in  Figure  2.  Each  layer 
encapsulates  a  very  well  defined  set  of  functionality  that 
isolates  the  next  higher  level  from  details  not  needed  at  that 
level.  This  enhances  the  reusability  of  the  code  at  all 
levels. 


inserted  into  the  appropriate  directory  in  formal  which  the 
application  can  manipulate  or  import.  From  the  viewpoint 
of  the  application  it  is  as  if  ll  is  running,  on  the  system  by 
itself,  using  us  normal  methods  of  non  real  lime  I/O. 


Message  Processing 


Figure  3.  Booch  Diagram  of  SMB  Tasking 

Object  Oriented  Design  was  used  to  provide 
flexibility  in  programming  the  embedded  I/O  boards  for 
connecting  different  types  of  I/O  devices  to  the  SMB  (4). 
The  details  of  the  embedded  processor's  operation  was 
encapsulated  into  two  objects,  the  SCC_PKG  and  the 
DMA_PKG.  Figure  4  is  a  Booch  diagram  of  the 
lOJTOOLS  which  includes  these  two  objects.  Figure  5 
shows  the  lOJTOOLS  physical  allocation  of  the  software 
between  the  host  and  embedded  processors  within  the 
hardware. 
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Figure  4.  Booch  Diagram  of  the  lOJTOOLS 


Figure  2.  System  Layering 

This  byering  approach  allows  Commercial  -Off-The- 
Shelf  (COTS),  Govemment-Off-The-Shelf  (GOTS)  and 
Military -Off-The-Shelf  (MOTS)  Ada  applications,  such  as 
word  processors,  to  be  integrated  into  the  system,  without 
the  need  for  modification  of  the  application  itself.  This  is 
accomplished  through  the  use  of  Ada  Tasking  as  shown  in 
Figure  3.  The  lOJTOOLS  and  the  application  are  run  as 
separate  tasks.  These  tasks  have  no  need  to  communicate 
directly  nor  rendezvous.  The  lOJTOOLS  insures  that 
incoming  message  traffic  is  assembled  into  files  and  are 


The  lOJTOOLS  has  a  message  passing  scheme  to 
transfer  commands  and  dab  between  the  host  and  the  I/O 
boards  The  board  to  host  interface  is  pertorined  ti trough 
shared  memory.  The  primary  packages  of  the  lOJTOOLS 
are  described  as  follows. 

MSG_DEF_PKG:  Contains  type  definitions  for 
messages  that  will  be  passed  between  the  IO_TOOLS 
software  on  the  I/O  board  and  the  host  software  on  the  PC. 
Additional  IO_TOOLS  capabilities  can  be  provided  by 
expanding  the  message  definitions  and  providing  the 
appropriate  processing. 
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N1HOX  PKG  [ K:lincs  [he  (yjx's  ami  u(>cratioi:s  M 
implement  mailboxes  (or  (he  IO  TOOLS  and  (lie  liosi 
software  Messages  are  delivered  and  removed  Irorn  a 
specific  "users''  mailbox  Users  are  the  iO  TOOLS  and  (he 
host  software.  When  a  message  is  read  from  a  mailbox,  the 
receiver  acts  on  the  message  Commands  arc  acted  on  and 
status  information  is  processed  accordingly. 
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Figure  5.  Software  to  Hardware  Allocation 

SCC_PKG:  Provides  an  interface  to  the  Zilog 
Z8530  Serial  Communications  Controller  (SCC)  chip  on 
the  I/O  boards.  It  further  provides  a  high  level  interface  to 
the  low  level  chip  operations.  Every  primary  operation  of 
the  chip  is  represented  even  though  only  a  subset  is  used. 

DMA_PKG:  Provides  an  interface  to  the  Intel 
8237A  Direct  Memory  Access  (DMA)  chip  on  the  I/O 
board.  It  also  provides  a  high  level  interface  to  the  low 
level  chip  operations.  Every  primary  operation  of  the  chip 
is  represented  even  though  only  a  subset  is  used. 

PORT_PKG:  Contains  the  operations  to  read  and 
write  data  to  and  from  the  specified  port  on  a  specified  I/O 
board.  Overloaded  operations  are  provided  to  read  and  write 
data  of  different  sizes. 

DOUBLE_LIST:  Provides  operations  to  manipulate 
the  abstract  data  type  L1ST_ID,  which  is  a  double  linked 
list  of  objects.  DOUBLE_LlST  is  a  generic  package  and 
the  type  of  the  list  object  is  declared  at  instantiation.  It 
provides  operations  to  add  objects  to,  delete  objects  from 
and  extract  objects  from  the  list.  It  allows  the  user  to  move 
about  and  manipulate  the  list  in  various  ways,  such  as 
advance,  backup,  go  to  first,  and  go  to  a  specific  element  in 
the  list.  List  status  operations  are  also  provided. 

MSG_LIST_PKG:  An  instantiation  of  the 

DOUBLh_LlST  package  for  MSG_TYPE  defined  in 
MSG  _DEF  PKG.  Used  to  defin"  bnked  lists  cf  messages. 
The  linked  lists  store  messages  for  transmission  until  they 
can  be  placed  in  a  specified  users  mailbox. 

Processes  and  Methodologies 

The  SMB  Software  development  process  focused 
around  an  Evolutionary  Prototyping  approach,  under  a 
tailored  DoD-STD  2 167  A  (5).  As  will  be  detailed  in  the 


mctiu  s  sei  linn  ul  thi'.  p.ijH-i  tin  ■  .ij'i'HM.  h  .ill. •  l-  ii  : 
usk  management  while-  .illnvvmg  lleiihililv  in  |l.<  |r  i,n 
lurthei  tins  appoint  h  i  omhined  with  A.  l.i  -I  l  •> .c  r  ■  ■  u  v 
provided  a  mimtiei  ol  very  imj*>tlaiii  advantage’  <  )u<-  i. 
that  t  allow  ed  die  very  rapid  development  of  a  .  ••in.  i<-tc 
executable  model  ol  the  proposed  system  Shis  w.r- 
important  as  the  sponsor  and  end  usets  eould  (hen  evaluate 
tlie  actual  behavior  o(  the  system  against  (heir  exportations 
Anotfter  advantage  is  that  it  allowed  the  sjKinsor  to  bind  lU- 
initial  work  as  risk  reduction  and  (hen  only  fully  fund  ideas 
tha(  acti  ally  work.  Sponsor  and  end  usei  reaction  have 
been  very  favorable  This  favorable  rear  lion  has  taken 
much  of  the  stress  that  developers  usually  have  when  trying 
toestablLsh  a  requirements  baseline  from  sc  ratch 

As  staled  above.  Object  Oriented  Design  was  used  as 
lire  design  methodology.  This  methodology  fits  very  nicely 
with  the  Evolutionary  IToiotyping  approach  Tins  is  due 
to  its  iterative  nature  and  support  for  subsystems  definition 
(6).  With  each  prototype  the  next  iteration  on  the  object* 
within  the  system  can  occur  giving  (he  needed  next 
increment  of  functionality.  Subsystems  are  used  to  decrease1 
the  complexity  of  the  system  Object  Oriented  Design 
provided  the  method  for  the  decomposition  of  the  reused 
Ada  software  into  these  software  subsystems  It  also 
provided  the  methodology  for  the  design  of  the  Tasking 

Environment 


One  of  the  goals  staled  above  was  to  support  for  a 
reusable  component  library.  An  Integrated  Programming 
Support  Environment  (IPSE)  has  been  assembled  which 
functions  as  the  local  software  repository,  development 
facility  and  configuration  management  system.  The  heart 
of  this  IPSE  is  the  excellent,  state-of-the-art  Rational  R- 
1000  Senes  400  Ada  Development  Environment.  The 
Raiional  allows  very  tight  coupling  of  all  project  tools  and 
products  and  is  integrated  as  shown  in  Figure  6. 
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Figure  6.  IPSE  Integration 
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The  Alsys  Ada  compiler  loi  MS  -DOS  ua\  used  on 
ihc  host  PC?  with  the  Alsys  Ada  Cross  compiler  lor  Intel 
processors  used  for  the  I/O  boards  The  compilers 
integrated  with  the  Rational  (through  the  use  of  Rational's 
Remote  Compiler  Integrator)  have  provided  us  with  an 
unmatched  capability  for  Ada  software  development 

Incremental  Reviews 

Using  the  Evolutionary  Prototyping  software 
development  process  often  presented  problems  for  meeting 
the  requirements  of  Formal  Reviews.  Formal  Reviews  arc 
defined  by  MIL-STD-1521  [7j.  The  purpose  of  these 
reviews  are  to  provide  the  sponsoring  agency  with  insight 
into  the  development  necessary  to  determine  that  it  is  on 
track  in  terms  of  budget,  schedule,  and  requirements. 
However  MIL-STD  1521  specifies  requirements  for  each 
review.  As  such  no  detailed  design  can  occur  before  all  the 
preliminary  design  is  complete  and  the  preliminary  design 
cannot  begin  until  all  the  system  specifications  are 
complete.  This  clearly  is  not  suitable  for  the  Evolutionary 
Prototyping  software  development  process.  Consequently 
we  initiated  the  Incremental  Design  Review.  The  concept 
is  that  a  Formal  Design  Review  is  satisfied  incrementally 
by  having  several  smaller  User  Evaluation  Reviews.  This 
is  shown  conceptually  in  Figure  7. 
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Figure  7.  Incremental  Reviews 

Software  Reuse  Model 

The  software  development  reuse  strategy  for  SMB 
was  driven  by  minimizing  software  development  costs 
through  increasing  productivity  and  quality  [8],  However 
effective  software  reuse  requires  an  architectural  framework 
[9!.  To  put  this  framework  into  quantitative  terms,  a  model 
of  software  reuse  and  its  associated  payoff  as  a  function  of 
software  development  phase  was  defined.  This  model  is 
described  as  follows. 

A  software  development  consist  of  KDS1 
(Thousands  of  Delivered  Source  Instructions).  Of  that 
amount,  let  r  be  the  maximum  amount  of  reusable  software 
defined  on  the  interval  (0,  1.0).  Here  software  reuse 
includes  requirements,  documentation,  design,  code  and 
testing.  Software  reuse  is  rarely  accomplished,  if  ever, 
without  some  redesign,  recoding  or  integration  and  testing; 
this  effort  is  encapsulated  in  the  Adaptation  Adjustment 
Factor  (AAF).  (The  notation  in  this  section  follows  fl  1)) 


I  Inis  the  AAF  lianslomiv  the  i*Kl)SI  into  an  Equivalent 
I)SI  (Hl)Sl)  and  the  cost  <>l  developing  the  software  tor  the 
Emticddcd  Mode  is 

3  21(1  DKDSI)1  ‘  *  (i'F.DSIj1  ‘  ] 

Hie  AAF  also  encapsulates  the  behavior  of  software 
reuse  as  a  function  of  life  cycle  At  the  bcginn,"g  of  the 
software  development,  the  factors  effecting  the  AAF  are 
most  favorable  Factors  which  normally  limn  reuse  are 
typically  most  lenient  at  the  beginning  of  the  life  cycle 
As  the  development  progresses,  introducing  software  reuse 
becomes  more  difficult  Consequently  the  amount  of 
design  modification,  (DM)  code  modification  (CM)  and 
integration  and  testing  (IT)  increases  as  the  development 
ages.  As  shown  >n  Tabic  I .  the  AAF  was  very 
conservatively  allowed  to  age  from  13%  to  33%. 
Introducing  reuse  al  the  end  of  the  Test  Readiness  Review 
or  Functional  Qualification  Testing  is  meaningless  in  our 
model.  The  results  of  our  calculations  arc  shown  in  Figure 
8  for  reuse  ratios  of  20,  50  and  80%. 
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Table  1.  AAFs  versus  End  Reviews 


When  Reuse  u* 


Initiated 

Figure  8.  Reuse  Payoff 

Phase  activity  distributions  were  allocated  as  6% . 
16%.  25%,  40%,  19%  for  the  phases  ending  in  the  System 
Specification  Review  (SSR).  Preliminary  Design  Review 
(PDR),  Critical  Design  Review  (CDR),  Test  Readiness 
Review  (TRR)  and  Formal  Qualification  Testing  (FQT) 
respectively.  The  payoff  is  defined  as  a  percentage  of  cost 
savings  when  compared  with  a  normal  development  not 
using  any  software  reuse.  Thus  payoff  normalizes  out 
several  of  the  calibration  factors.  These  calculations  show 
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that  llte  potential  cost  savings  drops  to  h\,\  than  trail  nt  tf it- 
maximum  amount  possible  il  von  wait  until  Ciihcal 
Design  Review  to  start  scan  lung  lor  code  to  reuse 
Alternttlivcly .  you  can  double  yom  cost  savings  hy 
implementing  reuse  Ik- I  ore  the  end  of  System  Specification 
Review. 

Project  Metrics 

Size  and  effort  estimation  techniques  have  been  used 
extensively  during  the  software  development  process.  The 
size  metric  is  based  on  terminal  semicolons.  (TSC).  and 
Delivered  Source  Instructions  (DS1).  For  the  original 
JAMES  software  (referred  to  in  ( 3|  as  JAMH)  which  formed 
the  core  of  the  SMB,  there  were  9,379  TSC  and  17.437 
DSI. 

In  December  1988  the  first  size  estimate  of  SMB 
based  on  Function  Point  Analysts  1 10)  produced  an  estimate 
of  2,200  TSC  (or  4.100  DSI)  with  a  high  and  low  of  2.870 
and  1,550  TSC  respectively  and  2,060  TSC  using  the 
Delphi  Expert  Method  (11).  The  additional  functionality 
required  to  reach  Prototype  11  is  listed  in  Table  2.  Table  2 
identifies  the  estimated  size  of  each  function  in  TSCs 
obtained  from  the  Delphi  Expert  Method  and  its 
corresponding  difficulty,  D,  to  develop  and  integrate  each 
function  with  respect  to  the  existing  software.  The 
difficulty  attribute  was  assumed  to  indicate  risk.  The 
difficulty  attribute  rating  ranged  from  Easy.  (E),  Nominal 
(N),  or  Hard  (H). 

The  sizing  estimate  obtained  from  Function  Point 
Analysis  does  not  lend  itself  to  be  partitioned  into  the  same 
functionality  groupings  with  which  the  users  are  familiar. 
For  example,  a  Function  Point  is  based  on  the  number  of 
input  files,  data  fields  and  output  files.  Thus  it  becomes 
very  difficult  to  map  Function  Points  into  the  functions 
shown  in  Table  2. 

Over  the  following  six  months,  as  Prototype  I  was 
tested  and  demonstrated,  the  functional  requirements  were  re¬ 
evaluated  during  User  Evaluation  Meetings.  Functionality 
was  added,  deleted,  modified  and  re  prioritized.  This 
revision  process  was  permitted  so  long  as  the  total  effort 
and  risk  remained  nearly  constant.  In  fact  knowing  the 
inherent  uncertainties  in  this  process,  we  required  the  effort 
and  risk  be  smaller  than  the  original  estimate  given  in 
Table  2. 

Users  submitted  the  form  shown  in  Figure  9  at  the 
User  Evaluation  Reviews.  Subsequently,  functional 
requirements  were  analyzed  and  size  and  difficulty  estimates 
were  derived  for  each  functional  requirement  and  presented  to 
the  program  sponsor.  Using  this  data,  the  sponsor 
redirected  Prototype  II  consistent  with  keeping  the  total 
effort  and  risk  less  than  the  original  estimates.  Table  3 
shows  the  results  of  this  process  as  baselined  for  Prototype 
II.  The  list  of  functions  desired  by  the  users  produced  a 
table  many  pages  long.  This  table  shows  that  (he  estimate 
of  the  total  effort  was  reasonably  accurate,  within  20%.  but 
sizing  the  individual  functions  had  a  high  variance.  This 
indicates  the  risk  in  trading  off  one  function  against 
another. 


in  tin-  otigmal  tost  analysis.  tin-  soliw.isi 
development  requited  to  menrpoiulc  the  IAMFS  sultwatc 
and  provide  I he  functionality  shown  in  I  aide  2  w.ts 
estimated  to  be  S540K  (1990  dollars)  over  a  ?2  month 
development  schedule  [  12]  The  cost  ol  a  new  development 
without  the  benefit  of  the  software  reuse  was  estimated  to 
be  S2.600K.  Based  on  tins  estimate.  S545K  was  allocated 
over  24  months.  After  17  months  into  the  development 
schedule.  Prototype  II  software  development  was  completed 
and  successfully  tested.  The  remaining  seven  months  will 
be  used  to  bring  the  software  from  Prototype  II  to  a  formal 
product,  which  includes  completing  the  DoD  STD  2167 A 
documentation. 


Function 

TSC 

1) 

1. 

Memory  Management 

200 

H 

2. 

ASCII-Baudot  Conversion 

10 

E- 

3. 

I/O  Port  Setup 

100 

E 

4. 

Receive  Message  Buffer  Rush 

50 

E 

5. 

Variable  Length  Message  Lines 

50 

N 

6. 

Blank  Message  Form 

50 

H 

7. 

SPECAT  Message  Handling 

50 

N 

8. 

Visible  Non-Printing  Edit 
characters 

100 

N 

9. 

Message  Catalog  Sorting 

750 

N 

10. 

Message  Format  Idcntificauon 

200 

N 

11. 

Message  Type  Idcntificauon 

50 

L 

12. 

Message  Parsing 

100 

N 

13. 

File  Wipe 

100 

H 

14. 

Floppy  Disk  Access 

50 

K 

15. 

S A  21 12  Switch  Control 

200 

N 

• 

Total 

2,060 

Table  2.  Initial  Requirements  and  Estimated 
TSC  for  Prototype  II 


— 

Function 

Est 

TSC 

D 

TSC 

1. 

Memory  Management 

200 

H 

514 

2. 

ASCII-Baudot 

Conversion 

10 

E 

108 

3. 

I/O  Port  Setup 

100 

f: 

171 

4. 

Receive  Message  Buffer 
Flush 

50 

E 

19 

5. 

Variable  Length  Message 
Lines 

50 

N 

1 

6. 

Message  Parsing 

100 

N 

871 

8. 

Message  Format 
identification 

SSIXS  Message 
Processing 

200 

100 

N 

7. 

Message  Catalog  Sorting 

750 

N 

98 

9. 

Floppy  Disk  Access 

50 

E 

68 

10. 

Security 

50 

N 

68 

11. 

Duplicate  Search 

200 

N 

47 

Total 

1.760 

2.165 

Table  .3.  Final  Requirements  and  Estimated  vs. 
Actual  TSC  for  Prototype  II 
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Date 
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Critical: 
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Add 
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Modify 
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-  dy : _ 

AcUaa: _  _ _ 


EatlauM  LOC: 
Dal* 


Figure  9.  User  Evaluation  Form 


Lessons  Learned 

PC  class  computers  are  capable  of  the  same 
functionality  inherent  in  expensive  minicomputers  currently 
used  in  the  DoD  for  message  processing. 

Ada  can  be  used  on  PC  class  computers  and  still 
meet  real-time  message  processing  requirements. 

Ada  software  reuse  can  significantly  decrease 
program  costs,  but  only  if  combined  with  a  well  defined 
software  development  process. 

Partnership  with  Ada  Joint  Program  Office  can 
greatly  enhance  the  Ada  Software  Engineering  solution  to 
difficult  problems. 

Future  Directions 

DoD  requirements  and  the  need  for  more  flexible  real 
time  Command,  Control  and  Communications  systems  are 
steadily  increasing  the  need  for  information  and  computer 
security.  This  translates  into  software  with  Mandatory 
Protection  (B  level)  certification  and  above  (13] 
Traditionally  the  more  trust  needed  in  one  of  these  systems 
the  higher  the  costs.  The  highest  level  systems  certified  for 
use  at  B  level  and  above  represent  investments  of  millions 
of  dollars  and  years  of  time  for  development.  The  need  for  a 
low  cost,  rapid  development  solution  to  this  problem  is 
required.  The  NRaD  Operational  Systems  Branch  is 
currently  working  on  a  solution  to  this  problem.  A  set  of 
bindings  to  the  secure  PC  version  of  System  V  UNIX. 


Iiusied  XENIX,  is  tx-mg  dcvelojx'd  111  paiiiunslup  »uh  liir 
AJ1*0  and  Spare  and  Naval  Waifaie  Ns  stems  Command.  In 
conjunction  with  the  already  developed  K)  TOOLS,  this 
software  will  provide  a  real  nine  B2  level  secure  system 
Further  tins  will  lower  risk  to  make  reuse  of  Ada  in  future 
Trusted  System  successful. 

Summary 

This  paper  has  discussed  the  processes  and 
methodologies  that  have  gone  into  the  making  of  an 
embedded  real-time  system  from  software  reuse. 
Evolutionary  Prototyping  combined  with  Object  Oriented 
Design  has  proven  very  effective  for  the  implementation  of 
the  Submarine  Message  Buffer  System.  Further  this 
effectiveness  has  translated  directly  into  shorter  development 
times  and  substantial  cost  savings.  However  no  process  i.> 
a  "magic  bullet".  The  success  achieved  during  the 
development  of  this  system  is  in  a  large  part  due  to  the 
experience,  training  and  dedication  of  the  development  team, 
both  at  NRaD  and  SPA  WAR. 
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